IBIS Macromodel Task Group Meeting date: 02 July 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Arpad: We can discuss the planned agenda items in any order. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Fangyi to add Tx_DCD example to BIRD 155 ------------- New Discussion: Interconnect update: - Walter: meeting tomorrow will discuss new Si2 release. - Will be in editorial mode after that. BIRD 155 New AMI API to AMI_Resolve Dependent Model Parameter: - Arpad showed the updated BIRD 155. - Fangyi: Tx_DCD depends on Tx_V and data rate. - This example of AMI_Resolve was added. - Ambrish: This looks good. - Walter: Another parameter might help. - Ambrish: Some parameters will appear twice. - Radek: Not sure if the parameter descriptions should be repeated. - Todd: AMI_Resolve outputs can't be passed back to AMI_Init? - Then only analog models and jitter budgets can be resolved. - Fangyi: Those are the only places AMI_Resolve is needed. - Todd: Tx_DCD is handled by AMI_Init, how does that work? - Walter: That one is a poor example, it is Info only. - Fangyi: AMI_Resolve would only be needed for analog. - Walter: Rx_Receiver_Sensitivity would be a good example. - Radek: Also there could be future parameters. - For example Tstonefile. - Fangyi: The Usage Dep is to prevent both AMI_Resolve and AMI_Init from updating it. - Radek: The current Out parameters would be split into Out and Dep - Ambrish: What about jitter? - Fangyi: Info parameters are only read by the EDA tool. - Walter: Rx_Receiver_Sensitivity is InOut. - Can it be Dep? - IBM has a bunch of Info parameters, for example. - There are a number of dependencies. - Fangyi: It should be Out, and AMI_Init should resolve it. - Walter: They have one DLL for a whole range of models. - It is controlled by configuration settings. - With this proposal they would have to generate new DLLs. - Fangyi: Model_Specific In String parameters can configure the DLL. - It could be a configuration file name. - Walter: The jitter parameters are Info so the simulator could not change them. - Fangyi: That is a separate problem. - Ambrish: Why are the AMI_Resolve parameters not in Reserved_Parameter or Model_Specific? - Bob: Any Out parameter could be a Dep. - Radek: Not simultaneously. - Ambrish: Any Info parameter should also be Dep? - Radek: It could be, not should be. - Todd: Dep is input to AMI_Resolve? - Fangyi: No, Dep is the output of AMI_Resolve. - All In and InOut parameters are sent to AMI_Resolve. - Walter: And anything needed for AMI_Resolve also goes to AMI_Init. - We are having trouble with overloading. - I have a presentation about this. - Todd: In the Tstonefile example the DLL knows which s4p to pass back? - The Dep parameters are to be treated by the EDA tool as Info. - Radek: Maybe there should be In parameters for this too. - David: What if the DLL returns non-sense? - Fangyi: The tool has to check. - Arpad: The DLL could store the names internally without be given the list. - David: Part of the reason for this is IP protection. - Giving the qualifiers in advance takes that away. - Fangyi: It is just an example. AR: Fangyi send BIRD 155 update to Mike for posting - Arpad showed an email from Walter. - Walter: I propose a Dependency_Usage leaf with values In or Out. - Walter explained the flow. - AMI_Resolve_Close would be called. - David: Why is that necessary? - Walter: To free memory. - Radek: Fangyi brought that up last week. - Walter: This would make the inputs and outputs explicit. - Radek: There would have to be rules about name collisions. - Walter: But now AMI_Init has an input it normally doesn't need. - Arpad showed an email from Fangyi. - Fangyi: It says Usage Out can't be dependent. - My concern is about InOut. - Radek: The information is sent to the EDA tool but will be modified later. - Walter: For example a tap coefficient might be determined by AMI_Resolve. - In PCIgen 3 & 4 the DFE will optimize taps then report what it did. - Fangyi: This is just for the analog channel. - Walter: There may be other purposes, we should not limit ourselves. - Ambrish: Why does there need to be Out parameters? - Walter: In BIRD 160 we have a parameter passed in, nothing says it can't be Usage Out. - All an EDA tool can do with Model_Specific Out parameters is report their values. - Radek: AMI_Resolve is almost at the same stage as AMI_Init. - Arpad: BIRD 160 limits to In or Info. - Fangyi: I see nothing that our proposal will not address. - Walter: I see nothing that my proposal will not address. - Ambrish: Dependency Usage is cleaner. - Walter: Also a Dep can not by output by AMI_Init. - My proposal gives flexibility to IC vendors with no cost to EDA vendors. - Ambrish: It's complex. - Fangyi: It's not logical. - Walter: AMI_Init has information AMI_Resolve does not, like the impulse response. - Ambrish: Information can already be displayed to the user. - Walter: Not if it's a Dep. - Fangyi: Jitter parameters can be modified later. - Walter: They can't, they are Info. - Ambrish: That could be allowed. - Walter: We would have to say which Info parameters could be Dep. ------------- Next meeting: 09 July 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives